Could you add a README that documents a bit on how to use this version of the image builder? I didn't see one included in the diff.

Could you add a README that documents a bit on how to use this version of the image builder? I didn't see one included in the diff.

Sure, I can do that, but the intension is that its a "drop in replacement", the cli should take the same option and the configuration file format is the same.

If that's the case, could you just add a few lines on any of the Go specific stuff? If it's supposed to be the same, I don't think there's a need for a whole new document.

If that's the case, could you just a few lines on any of the Go specific stuff? If it's supposed to be the same, I don't think there's a need for a whole new document.

Sure, I will add something

If that's the case, could you just a few lines on any of the Go specific stuff? If it's supposed to be the same, I don't think there's a need for a whole new document.

Sure, I will add something

Done, feel free to reach out if you have questions or think other things should be added.

Thanks for adding that. On another note, is there a supported way for building the Go binary? I built it by cd $repo/go && go build -C cmd/image-builder -o image-build and running the executable directly. I ask because some repos have Makefiles where you can just run make like with the ochami CLI with some options to create a container or such and so there are different ways to run the tool. I think specifying would help keep everyone on the same page in case we need to troubleshoot later.

Thanks for adding that. On another note, is there a supported way for building the Go binary? I built it by cd $repo/go && go build -C cmd/image-builder -o image-build and running the executable directly. I ask because some repos have Makefiles where you can just run make like with the ochami CLI with some options to create a container or such and so there are different ways to run the tool. I think specifying would help keep everyone on the same page in case we need to troubleshoot later.

Your invocation is a supported approach 😄 , but yes we can add a Makefile like ochami if this gets close to being merged.

I ran image-build -config config.yaml with the config file from the main README and I got this.

[INSTALLER]2025/10/06 10:16:28 Cleaning up temporary directory /tmp/image-build-820598980
2025/10/06 10:16:28 Error building layer: failed to build layer: failed to install package groups: failed to install package groups: failed to run command in container: while running runtime: exit status 1

I also saw this in the output which may be useful for troubleshooting.

[INSTALLER]2025/10/06 10:16:28 Running command in container: [dnf -y groupinstall Minimal Install Development Tools --installroot=/mnt/target --setopt=reposdir=/mnt/target/etc/yum.repos.d --setopt=_db_backend=sqlite]
Main config did not have a _db_backend attr. before setopt
Unable to detect release version (use '--releasever' to specify release version)
Main config did not have a _db_backend attr. before setopt

You have enabled checking of packages via GPG keys. This is a good thing.
However, you do not have any GPG public keys installed. You need to download
the keys for packages you wish to install and install them.
You can do that by running the command:
    rpm --import public.gpg.key


Alternatively you can specify the url to the key you would like to use
for a repository in the 'gpgkey' option in a repository section and DNF
will install it for you.

For more information contact your distribution or package provider.

Problem repository: [dl.fedoraproject.org_pub_epel_8_Everything_x86_64_]

I'm not sure if it matters, but I'm not running a RHEL-based distribution.

I ran image-build -config config.yaml with the config file from the main README and I got this.

[INSTALLER]2025/10/06 10:16:28 Cleaning up temporary directory /tmp/image-build-820598980
2025/10/06 10:16:28 Error building layer: failed to build layer: failed to install package groups: failed to install package groups: failed to run command in container: while running runtime: exit status 1

I also saw this in the output which may be useful for troubleshooting.

[INSTALLER]2025/10/06 10:16:28 Running command in container: [dnf -y groupinstall Minimal Install Development Tools --installroot=/mnt/target --setopt=reposdir=/mnt/target/etc/yum.repos.d --setopt=_db_backend=sqlite]
Main config did not have a _db_backend attr. before setopt
Unable to detect release version (use '--releasever' to specify release version)
Main config did not have a _db_backend attr. before setopt

You have enabled checking of packages via GPG keys. This is a good thing.
However, you do not have any GPG public keys installed. You need to download
the keys for packages you wish to install and install them.
You can do that by running the command:
    rpm --import public.gpg.key


Alternatively you can specify the url to the key you would like to use
for a repository in the 'gpgkey' option in a repository section and DNF
will install it for you.

For more information contact your distribution or package provider.

Problem repository: [dl.fedoraproject.org_pub_epel_8_Everything_x86_64_]

I'm not sure if it matters, but I'm not running a RHEL-based distribution.

Let me take a look, I mainly tried the ones in examples/ but it would work ...

@davidallendj The problem is that --gpgcheck defaults to true ( same a the python ) but that config is not providing any urls for the gpg keys. Try with --gpgcheck=false. This could be caught earlier in configuration validation ... Note: it will fail on the last command for id user as its not a valid user, as the buildah_extra_args: ['--volume', '/var/lib/sss:/var/lib/sss:z'] is not currently implemented, as it probably make more sense to support volume mount directly in the configuration if we have direct access to the buildad api, so just comment out the:

  - cmd: 'id user'
    buildah_extra_args: ['--volume', '/var/lib/sss:/var/lib/sss:z']

If we do want to maintain these options moving forward we can of cause do that too. I will update the README.md for now ...

I tried with your recommendations as well as a few in the examples directory and they both seemed to work without any issues.

I would like to get some consensus of whether we think this golang version is a viable/desirable replacement for the existing python version. Thanks to @davidallendj for taking it for a spin. Do others want to weight in? It would be good to make a decision/plan before two version diverge ( the in coming PR is part of my motivation for post this comment )